Ham Radio 2000/Ham Radio 2000.iso/ham2000/tcp_ip/jnos/psi110f/readme.lnx

Text File | 1993-09-16 | 9KB | 186 lines

This file (j109linux.zip) contains the patches and new files required to bring
JNOS 1.09 up under Linux.  An earlier version was tested partially under SCO
Unix as well.  Portability to other Unixes is unknown but is only likely to
work on i386/i486.

Instructions:

0) Get patch, if you don't have it already.
1) Unpack jnos08df.zip and new109.zip in your source directory.
2) Unpack this file in the same directory.  No files should be overwritten
   except config.h.  You may want to copy the new config.h to kf8nh.h.
3) Edit config.h to change the set of features you want to compile in.
   WARNING:  DO NOT TURN ON ANY OPTIONS NOT ALREADY TURNED ON.  You may, if
   you wish, turn options *off*.
4) Double-check the Makefile.  It should already be correct for Linux, except
   that you may want to turn off -static and -g3 (with -g3 the executable is
   nearly 3MB, most of which is debugging information) and turn on -O.
5) Type "make -f Makefile".  If you rename makefile (the original JNOS makefile
   unpacks to the lowercase name) to makefile.dos you can leave off the
   "-f Makefile".

I would appreciate it if DOS JNOS users would also test this, with the DOS
makefile.  I have tried to make sure that the patched source will still work
under DOS, but I cannot test this.  I would also like the DOS users to test
the non-Linux-specific changes:  MONITOR, AXBCSTR, and TTYCALL, all of which
are specified in config.h instead of the makefile.  The source does contain
several non-Linux-specific bug fixes, the most important of which is to at:
if two at jobs go off at the same time, memory will be severely corrupted in
the stock 1.09 code.

The file BSAHAX describes my changes in some detail, along with a list of
additional modifications planned.

Please send bug (and success, if any) reports to [e-mail].

++Brandon

----- BSAHAX --------

*** WG7J ***
Most mods have been added to 'stock' JNOS code.
If something has been changed it is noted in the same style as this note.
Johan, WG7J
************

Modifications to NOS 921129/PA0GRI/WG7J 1.09 by KF8NH:  (ver 0.6)

* Tracing.  A new mode "monitor" has been added which uses a compressed display
  format and displays AX.25 Text packets the way they look to users.  This is
  not JNOS-specific, although it all uses the modified trace routines which
  enable Unix to do asynchronous tracing.  Define MONITOR in config.h to
  enable this.  This uses the previously undefined flag combination
  TRACE_ASCII|TRACE_HEX.
  #define MONITOR

* AX.25 ttycall.  This is equivalent to an ordinary PBBS keyboard-to-keyboard
  connect; AX.25 connects to this call get fed directly to ttylink.
  #define TTYCALL

* 3-argument "ax25 bc".  You can now optionally specify a string to broadcast.
  I use this to get separate beacons on each interface, since one is on an IP
  frequency and the other is a user frequency.
  #define AXBCSTR

*** WG7J ***
  jnos 1.10 x4 has this included in the 'ifconfig <iface> bctext "text"'
  command. A little different, but same effect.
************


Support for Linux (386 *ix clone) and other POSIX-supporting *ix:

Compiling with -DLINUX and -DUNIX causes JNOS to be built for the Linux
environment.  This has quite a few differences in terms of implementation
but (hopefully) few, if any, user-visible differences.

* Display is asynchronous:  each session window continues to be updated even
  if it is not current.  Page mode becomes a bit more important with this
  change.

* The display management is done via curses.  There are also some hooks for a
  future modification allowing separate sessions to be passed to an external
  session manager.

* F1-F10 are supported via terminfo.  (Linux's termcap-based curses is too
  buggy for NOS to function; it dumps core when it tries to scroll.)  They
  have the same meanings as under the DOS version.  The arrow keys are also
  supported, and command history works.

* You can't run JNOS out of /etc/rc; it has to be interactive.  This will
  change in the future.

* Device types other than asy are NOT supported.  These will require kernel
  device drivers.

* Interfacing to the Linux TCP/IP system is NOT supported.  I consider this a
  potential security hole and will not consider adding this until I work out
  how to avoid misuse.

* Connects get the JNOS BBS; no provision for system logins is made, and none
  will be made.  This is an even bigger potential security hole than TCP/IP
  gatewaying; that is why I chose to port JNOS instead of running WAMPES,
  which has already been ported to Linux.  (Note that, because of the way
  WAMPES manages users, a malicious user could play a trick like setting their
  MYCALL to the name of a (non-root) user.)

* A completely different means of scheduling timers and checking for I/O is
  used, which is both more efficient and more responsive than the DOS method.
  Instead of using a 55-ms timer tick and checking for timers and I/O on each
  tick, the system sleeps on a select() on the asy ports and keyboard with a
  select timeout.  Timers cause the select timeout to be updated; when the
  timer is scheduled to go off, the select() will return regardless of pending
  I/O and the timer process will be scheduled.  (The timer process is always
  scheduled when the select() returns, since on most systems there is no way
  to tell if the timeout was about to expire when select() woke up.)  This
  should not cause any changes in the actual operation of JNOS, but makes it
  much less of a CPU hog; it should also enable JNOS to function with high
  speed devices, which I consider essential since the future of kf8nh.ampr.org
  is likely to include a PackeTwin and a 9600 baud or even 56Kbaud modem.
  (Yes, I will be designing a kernel driver and JNOS/Linux support at that
  time.)  ---Note:  a particularly slow operation will cause delays in I/O
  that aren't seen in the DOS version.  "dir" in the directory containing the
  JNOS source is one way to see this.  I'm still trying to decide the best way
  to handle this.  The cause isn't my code; it's the business of using a
  linear search and insertion to "sort" the directory list as it is received
  from findfirst/findnext, which is from the original code.  But if I change
  it to be efficient, it won't work with 64K segments.  Sigh.

The Linux support is at least partially portable, as Linux's native API is the
POSIX P1003.1 specification.  However, POSIX leaves several things unspecified
and others optional; for example, the asy management is POSIX, but I don't
expect to see DOS (usefully) supporting tcsetattr() in the near future :-)
select() is POSIX optional, but is utterly essential to JNOS.  The directory
utilities use statfs(), of which at least four (!) variants exist, none POSIX.
And so on.

The syntax for attaching an asy port is:

attach asy <device> <ignored> ax25|ppp|slip|nrs ...

the rest being the same as for the DOS version except that the "f" flag to
activate the 16550 FIFO will be ignored:  under Unix, that is the serial
driver's responsibility.  The device should not specify the "/dev" prefix.
(This will change in the future.)  JNOS will not currently share a port with
a dialout program, which will also change once carrier detect support is added.

TODO:

* Implement fkeys.  This will take some work, as I can't use KEY_* from
  ncurses (it blocks).  On the other hand, since I've already *got* key trie
  code, all I really need is tigetstr().  This also means that fkey can take
  key names from terminfo instead of cryptic numbers (not that the terminfo
  names are necessarily all that much better, mind you.... :-)

* Implement session manager support and detached consoles.  The folks who have
  to wait for me to start X so they can digi through me will undoubtedly thank
  me for this :-)  N.B. This will take real work.  Don't expect it soon.

* Look into compacting "monitor" even more.  This includes compacting
  the trace output for things I haven't looked at yet, like arcnet.  I don't
  think some things can be reasonably compacted, though (e.g. node lists).

* Implement RTS/CTS flow control.  Doable, but I can't test it.

* Implement DTR(=DCD).  Once again, SCO is a bottleneck (actually, System V in
  general):  you can't distinguish between a no-delay read with no data avail-
  able and a read with no carrier present.  Sigh.

* There have been some requests for SHELL to work.  Since I always have either
  a VC or an xterm available, I haven't bothered to make it work... it is not
  all that hard, however, all I need is an "inhibit refresh" flag and a stub
  to write a single byte to a pipe after the subshell exits, with request_io()
  on the pipe to catch the exit and re-enable updates.  (Also keyboard, of
  course.)

* Use a Unix format for ftp's LIST and NLST commands.  I'm holding off until
  I decide how to best map DOS attributes:  if I do this it will be usable
  under both, since some folks have requested a format that will work with
  point-and-shoot ftp client front-ends.

* Crossband digipeat aliases.  Currently, if you set a separate call on each
  interface that call can be used to crossband digipeat, but locally the
  convention is to use TOxxx aliases.  Ex. TO370 (gate to 223.70 BBS link),
  TO501 (145.01 user channel), etc.